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Abstract 


This document describes the architecture for supporting SPIRITS 
services, which are those originating in the PSTN (Public Switched 


Telephone Network) and necessitating the interactions between the PSTN 


and the Internet. (Internet Call Waiting, Internet Caller-ID 
Delivery, and Internet Call Forwarding are examples of SPIRIT 
services.) Specifically, it defines the components constituting the 
architecture and the interfaces between the components. 


1. Introduction 
This document describes the architecture for supporting SPIRITS 


services, which are those originating in the PSTN (Public Switched 
Telephone Network) and necessitating the interactions between the 


PSTN and the Internet. (Internet Call Waiting, Internet Caller-ID 
Delivery, and Internet Call Forwarding are examples of SPIRIT 
services.) Specifically, it defines the components constituting the 


architecture and the interfaces between the components. 
The rest of the document is organized as follows: 


+ Section 2 describes example SPIRITS services from the end-user 
point of view; 


+ Section 3 describes the SPIRITS architecture; 


Slutsman, et al. Informational [Page 1] 


RFC 3136 The SPIRITS Architecture June 2001 


+ Section 4 contains security considerations; 
+ Section 5 contains acknowledgments; 
+ Section 6 contains references; and 
+ Appendix contains the figure. 
2. Brief Description of Example SPIRITS Services 
To illustrate the motivation for the overall SPIRIT architecture, 
this section provides a brief description of the example SPIRITS 
services: 
+ Internet Call Waiting (ICW), 
+ Internet Caller-ID Delivery, and 


+ Internet Call Forwarding. 


These services are considered from the end-user point of view under 
the assumptions below: 


+ Service subscription (or cancellation) is a separate process and 
may be done over the telephone, via postal mail, or over the Web. 


+ The subscriber's IP host (e.g., a PC) is loaded with the necessary 
software [including a Personal Identification Number (PIN) and the 
IP addresses of the SPIRITS servers] for realizing the SPIRITS 
Services. The software may be sent by postal mail or downloaded 
from the Web. 


+ The subscriber activates a SPIRITS service by an act of service 
Session registration, which can take place anytime after he (or 
she) is connected to the Internet. The subscriber may specify the 
life span of the session. As soon as the session ends, the 
SPIRITS service is deactivated. Naturally, the subscriber should 
also be able to deactivate a SPIRITS service anytime during the 
Service session. 


For certain services (such as ICW or Caller-ID Delivery) the 
assumption is that the service subscriber has a single telephone line 
and a PC, which is connected to the Internet via this telephone. 
(Only under this assumption these services make sense.) 

Nevertheless, in other services (such as Web-based Call Center, in 
which a call center assistant could re-direct or reject a call 
presented in a pop-up window) this assumption may be unnecessary or 
even inapplicable. 
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2.1 Internet Call Waiting (ICW) 


The Internet call waiting service enables a subscriber engaged in an 
Internet dial-up session to 


o be notified of an incoming call to the very same telephone line 
that is being used for the Internet connection; 


o specify the desirable treatment of the call; and 
o have the call handled as specified. 


The details of the ICW service lie in the ways that a waiting call 
can be treated [1]. Typical ways for handling a call include: 


+ Accept the incoming call over the PSTN by terminating the Internet 
connection. (As switching cannot be done immediately, the caller 
may hear an opening announcement followed by the "ringing" tone.) 


+ Forward the incoming call to another telephone number. The 
subscriber will remain connected to the Internet, while the caller 
will hear an announcement indicating the call is being forwarded 
and eventually be connected to the new destination number. 


+ Accept the incoming call by voice over IP. The subscriber will 
answer the incoming call via the already established Internet 
connection. (The proposed SPIRITS architecture, however, does not 
reflect this feature.) 


+ Redirect the incoming call to voice mail. The subscriber will 
remain connected to the Internet, while the caller will hear an 
announcement inviting him (or her) to leave a message. 


+ Play a pre-recorded message to the calling party and disconnect 
the call. The subscriber will remain connected to the Internet. 


+ Reject the incoming call. The subscriber will remain connected to 
the Internet, while the caller will hear an announcement rejecting 
the call. 


The subscriber may specify the call treatment on the fly when 
notified of an incoming call. Alternatively, the subscriber may 
Specify a priori a general treatment for all calls (e.g., re-directed 
to voice mail) or call treatments tailored to the origination 
numbers. As a result, when a call comes in, the subscriber won't be 
presented the call but can examine afterwards the treatment and 
outcome of the call from the log that is kept for all the calls 
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processed during the ICW service. Typical information recorded in 
the log includes the incoming call date and time, calling party 
number, calling party name, and call disposition. 


2.2 Internet Caller-ID Delivery 


This service allows the subscriber to see the caller’s number or name 
or both while being connected to the Internet. If the subscriber has 
only one telephone line and is using the very line for the Internet 
connection, the service is a subset of the ICW service and follows 
the relevant description in Section 2.1. Otherwise, the subscriber’s 
IP host serves as an auxiliary device of the telephone to which the 
call is first sent. 


2.3 Internet Call Forwarding 


The Internet call forwarding service allows a service subscriber to 
forward an incoming call to another telephone number while being 
connected to the Internet. If the subscriber has only one telephone 
line and is using the very line for the Internet connection, the 
service is a subset of the ICW service and follows the relevant 
description in Section 2.1. Otherwise, the subscriber’s IP host 
serves as an auxiliary device of the telephone to which the call is 
first sent. 


3. SPIRITS Architecture 


Figure 1 of the Appendix depicts the SPIRITS architecture, which 
includes the following entities: 


1. Service Control Function (SCF) [2], which executes service logic, 
interacts with the entities in the IP domain (e.g., the SPIRITS 
Gateway and PINT Server) through the SPIRITS Client, and instructs 
the switches on how to complete a call. Physically, the SCF may 
be located in either stand-alone general-purpose computers called 
Service Control Points (SCPs) or specialized pieces of equipment 
called Service Nodes (SNs) [2]. 


2. Service Switching Function (SSF) [2], which normally resides in a 
switch and is responsible for the recognition of Intelligent 
Network (IN) triggers and interactions with the SCF. 


3. SPIRITS Client, which is responsible for receiving PSTN requests 
from the SCF as well as sending responses back. It may be co- 
located with the SCF. If not, it communicates with the SCF over 
the D interface. 
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4. PINT Server, which receives PINT requests from the PINT Client and 
relays them to the PSTN for execution over the E interface. 


5. SPIRITS Gateway, which is co-located with the PINT Server or PINT 
Gateway (or both when they are co-located as assumed here for 
simplicity) and serves as an intermediary between the SPIRITS 
Server and SPRITS Client via the B and C interfaces, respectively. 


6. PINT Client, which resides in the subscriber’s IP host and is 
responsible for initiating PINT requests, which are sent to the 
PINT server over the A interface. 


7. SPIRITS Server, which terminates PSTN requests and is responsible 
for all interactions (e.g., incoming call notification and 
relaying the call treatment) between the subscriber and the 
SPIRITS Gateway. 


The rest of the Section describes the interfaces between the entities 
in detail. 


3.1 Interface A 


This interface is used for sending PINT requests to PINT Server. Its 
principal use is for service session registration and as a result 
activation of a SPIRITS service (see Section 2). In addition, this 


interface may be used for service subscription. 
3.2 Interface B 


This interface serves two main purposes: 1) to notify the subscriber 
of incoming calls together with the calling number and name, if 
available; and 2) to send to the SPRITS Gateway the subscriber’s 
choice of call disposition specified on the fly. 


3.3 Interface C 


This interface is used for communications between the SPIRITS Client 
and SPIRITS Gateway. The SPIRITS Gateway may in turn communicate 
with the SPIRITS Server, or may act as a virtual server, terminating 
the requests without sending them down to the SPIRITS Server. 


3.4 Interface D 
This interface is for communications between the SPIRITS Client and 
the SCF. Specifically, from the SCF to the SPIRITS Client, the 


parameters associated with the applicable IN triggers are sent. From 
the SPIRITS Client to SCF, the subscriber’s call disposition is sent. 
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The SCF "transforms" the user’s disposition into appropriate actions, 
such as playing an announcement to the caller, and resuming the 
suspended call processing in the SSP. 


3.5 Interface E 
This interface is for sending PINT requests to the SCF for execution. 
4. Security Considerations 


As Figure 1 demonstrates, there are two distinct communications 
interfaces, B and C. The B interface is, in general, across the 
public Internet and is thus most vulnerable to security attacks 
resulting in theft or denial of service. The C interface, on the 
other hand is likely to be implemented across a service provider's 
intranet, where the security measures should be applied at the 
discretion of the service provider. Even then, because at least one 
IP host (the PINT gateway) is connected to the Internet, special 
measures (e.g., installation of firewalls, although this particular 
measure alone may be insufficient) need to be taken to protect the 
interface C and the rest of the network from security attacks. 


The assumption that the PINT Client and SPIRITS server are co- 
located, dictates that the security considerations for the A and B 
interfaces are exactly the same. Detailed security requirements and 
solutions for interface A (and, consequently, B) can be found in RFC 
2848 [3]. In addition, security requirements are listed in the 
companion SPIRITS Protocol Requirements RFC. 
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Figure 1: SPIRITS Architecture 
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Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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